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(57) Abstract: A system for providing information 
content over a network to a mobile communication 
device includes a transcoding system and a first network 
device. The transcoding system includes a plurality of 
transcoders. Each transcoder is operable to transcode the 
information content from a respective input content type 
into a respective output content type. The first network 
device is in communication with the transcoding system 
and includes a connection handler system. The first 
network device is operable to receive a first connection 
request that includes transcoder request data and to select 
a corresponding connection handler. The connection 
handler is operable to select one or more transcoders 
from the plurality of transcoders based on the transcoder 
request data. 
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SYSTEM AND METHOD FOR PROVIDING REMOTE DATA 
ACCESS AND TRANSCODING FOR A MOBILE COMMUNICATION DEVICE 

This application claims benefit of the following United States Provisional 

Applications: Serial No. 60/305,044, entitled "System And Method For Providing 

5 Remote Data Access For A Mobile Communication Device" and filed on July 1 2, 2001 ; 

Serial No. 60/327,752, entitled "System and Method For Providing Remote Data Access 

To A Mobile Communication Device" and filed October 9, 2001 ; Serial No. 60/330,604, 

entitled "System And Method For Providing Remote Data Access And Transcoding For 

A Mobile Communication Device" and filed October 25, 2001; and Serial No. 

10 60/340,839, entitled "System And Method For Pushing Data From An Information 

Source To A Mobile Communication Device" and filed December 19, 2001. The 

complete disclosures of all of the above-identified provisional applications are hereby 

incorporated into this application by reference. 

15 Cross Reference To Related Applications 

This application is also related to the following co-pending Non-Provisional 
Applications: Serial No. / entitled "System And Method For Providing 

Remote Data Access For A Mobile Communication Device" and filed on a 

2002; and Serial No. _J l entitled "System And Method For Pushing Data 

20 From An Information Source To A Mobile Communication Device" and filed on 

1 2002, the complete disclosures of which are hereby incorporated into this 

application by reference. 

25 BACKGROUND 
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Field of the Invention 

This invention relates generally to mobile communications, and in 
particular to providing access to remote data from mobile communication devices. 

5 Description of the State of the Art 

Known solutions for providing remote access to data using mobile 
communication devices tend to be relatively limited. For example, Wireless Application 
Protocol (WAP) browsers for mobile devices typically provide access only to information 
associated with WAP-compliant sources. Although other known and similar products 

10 may allow a mobile device user to access further information sources, such products 
generally do not make efficient use of mobile communication network resources, 
particularly wireless communication links, and often require processor-intensive 
operations such as information parsing to be executed on the device. 

Furthermore, most known data access systems and methods are not 

15 suited to provide truly secure access to confidential information stored on private 
networks, such as corporate information located on a data store behind a security 
firewall. 

SUMMARY 

20 The instant application describes a system and method for providing 

mobile communication devices with access to remote information sources. A system 
and method for providing secure access to confidential information is also described. 

The systems and methods described herein provide for access to any of a 
plurality of types and formats of information. Particular information translation 



2 



WO 03/007183 PCT/CA02/01073 

operations may be selected by either a mobile communication device or an information 
source and performed on an information source side of a mobile communication 
system. This not only reduces the complexity of device processing operations and any 
device hardware and software components associated with such operations, but also 

5 provides for customized device information formats. 

In one embodiment, a system for providing information content over a 
network to a mobile communication device includes a transcoding system and a first 
network device. The transcoding system includes a plurality of transcoders. Each 
transcoder is operable to transcode the information content from a respective input 

10 content type into a respective output content type. The first network device is in 
communication with the transcoding system and includes a connection handler system. 
The first network device is operable to receive a first connection request that includes 
transcoder. request data and to select a corresponding connection handler. The 
connection handler is operable to select one or more transcoders from the plurality of 

15 transcoders based on the transcoder request data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a general block diagram of a communication system that provides 
access to a remote information source from a mobile communication device. 
20 Fig. 2 is a more detailed block diagram of the system shown in Fig. 1 . 

Fig. 3 is a flow chart representing general connection handler-related 
operations in the system. 

Fig. 4 is a flow chart of connection handler data processing operations. 

Fig. 5 is a signal flow diagram illustrating an example of device-controlled 
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transcoder selection for an HTTP connection. 

Fig. 6 is a signal flow diagram representing device-controlled transcoder 
selection with extension of accepted content types. 

Fig. 7 is a signal flow diagram of an example of server-controlled 
5 transcoder selection for an HTTP operation . 

Fig. 8 is a general block diagram of a communication system with an 
external transcoder system. 

Fig. 9 is a signal flow diagram illustrating an example of device-controlled 
transcoder selection for an HTTP connection with an external transcoder system such 
10 as shown in Fig. 8. 

Fig, 10 shows a further signal flow diagram for an external transcoder 

system. 

Fig. 1 1 is a block diagram showing an IP Proxy system implemented in a 
secure network. 

15 Fig. 12 is a signal flow diagram illustrating a corporate data access 

operation. 
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DETAILED DESCRIPTION 

General System Description 

Fig. 1 is a general block diagram of a communication system that provides 
access to a remote information source 20 from a wireless mobile communication device 

5 ("mobile device") 12. In Fig. 1 , the system 10 includes a mobile device 12, a wireless 
network 14, a gateway 15, a wide area network (WAN) 16, an Internet Protocol (IP) 
Proxy system 18, and an information source 20. Although an IP Proxy system 18 is 
shown in the illustrative example system of Fig. 1, proxy systems for protocols other 
than IP may be implemented in accordance with the present invention. Protocols at 

10 other levels within the Open Systems Interconnection (OSI) model can also be proxied 
using this system. Such other protocols include but are not limited to Hypertext 
Transfer Protocol (HTTP) and Transmission Control Protocol (TCP). 

The mobile device 1 2 may be any mobile device adapted to operate within 
a wireless communication network 14, and is preferably a two-way communication 

15 device. The mobile device 12 may have voice and data communication capabilities. 
Depending on the functionality provided by the mobile device 12, the mobile device 1 2 
may be referred to as a data messaging device, a two-way pager, a cellular telephone 
with data messaging capabilities, a wireless Internet appliance or a data communication 
device (with or without telephony capabilities). As will be apparent to those skilled in the 

20 field of communications, the particular design of a communication subsystem within the 
mobile device 12 will be dependent upon the communication network 14 in which the 
mobile device 12 is intended to operate. For example, a mobile device 12 destined for a 
North American market may include a communication subsystem designed to operate 
within the Mobitex™ mobile communication system or DataTAC™ mobile 



5 



WO 03/007183 PCT/CA02/01073 

communication system, whereas a mobile device 12 intended for use in Europe may 
incorporate a General Packet Radio Sen/ice (GPRS) communication subsystem. Those 
skilled in the art will also appreciate that other types of mobile devices and networks are 
also contemplated. The inventive systems and methods described herein may be 

5 implemented in conjunction with virtually any wireless network 14. 

The gateway 15 shown in Fig. 1 provides an interface between the 
wireless network 14 and a WAN 16, which may, for example, be the Internet. Such 
functions as mobile device addressing, conversion of data between WAN protocols and 
wireless network protocols, storing and forwarding data to and from the mobile device 

10 12, and other interface functions may be* performed by the gateway 1 5. 

It is also possible that an IP Proxy system 18 could be hosted by a 
network carrier/operator associated with the wireless network 14. In this case, the 
connection between the IP Proxy system 18 arid the gateway 15 would use a private 
network of the carrier instead of the WAN 16. The WAN could then be used to 

15 communicate between the IP Proxy system 18 and the information source 20. 

The IP Proxy system 18 is a system that effectively provides the mobile 
device 12 with access to the information source 20 and is described in further detail 
below. Through the IP Proxy system 18, the mobile device 12 may access any 
information source 20, such as an Internet or web server, that can communicate with 

20 the IP Proxy system 18. The information source 20 therefore requires no special 
applications or protocol support for wireless network communications, since it 
communicates with the IP Proxy system 18 and not directly with the mobile device 12. 
Although shown in Fig. 1 as a direct connection, the IP Proxy system 18 and 
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information source 20 may also communicate through a network such as a local area 
network (LAN) or WAN, including the Internet. 

Wireless networks and the Internet use similar addressing schemes, in 
which recipients, such as mobile devices in a wireless network or Internet-connected 

5 computers, are identified by numerical addresses. For example, mobile devices are 
identified in the Mobitex network using Mobitex Access Number (MAN) and public 
Internet nodes are identified using an IP address scheme. However, differences 
between wireless network and Internet transport mechanisms prevent direct 
communication between information sources 20, the vast majority of which are Internet- 

10 based, and mobile devices 12. Furthermore, information source content is largely 
targeted to desktop or other computer systems with relatively powerful processors and 
may require that processor-intensive operations such as information parsing be 
performed by a recipient. Since mobile devices tend to have less powerful processors, 
these operations take more time on such mobile devices than on computer systems and 

15 can consume significant amounts of power from normally limited-power sources. The IP 
Proxy system 1 8 bridges the gap between Internet-based and possibly other information 
sources 20 and a wireless network 14 with associated mobile devices 12. The services 
supported by the IP Proxy system 18 may include address mapping, content 
transformation and verification, and protocol mapping and optimisation, for example. 

20 

Detailed Description of the IP Proxy System 

Fig. 2 is a more detailed block diagram of the IP Proxy system 18 shown 
in Fig. 1 . The IP Proxy system 1 8 may include a dispatcher 22, a TCP handler 24, an 
HTTP handler 26, a transcoding system 28, one or more push sen/ices generally 
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designated 30, a state persistence element 34, a monitoring system 36, and a logging 
system 38. Fig. 2 also shows a push server 42, a web server 46, a web browser 48, and 
a file system 40, with which the IP Proxy system 18 may interact from time to time. 
Many of the components shown in Fig. 2 may be implemented primarily as computer 

5 software modules. Elements within the IP Proxy system 1 8 will typically be running on 
the same computer, whereas components external to the IP Proxy system 18 are 
normally resident on separate computers. In another embodiment, however, the 
elements of the IP Proxy system 18 may instead be distributed among a group of 
computers distributed over a network. 

1 o Dispatcher 22 manages data flows and the connection to the gateway 1 5. 

Depending on the type of connection or the type of data being transferred or data 
transaction being performed for example, the dispatcher 22 interacts with the TCP 
handler 24 or the HTTP handler 26. The transcoding system 28 comprises one or more 
data filters, each of which converts data or other information from one format into a 

15 format that can be processed by a mobile device 12. 

Push services 30 provide for transfer of "unsolicited" information from an 
information source such as push server 42, which may for example be a web server or 
a software application, to a mobile device 1 2 through the IP Proxy system 1 8. The push 
services component 30 allows the push server 42 to address the mobile device 1 2 using 

20 for example the email address of the mobile device owner or some other convenient 
label. Accordingly, the push server 42 need not know the address of the mobile device 
1 2 in the wireless network 1 4. The state persistence element 34, in conjunction with a 
data file system 40 or a database, enables management of cookies, passwords and 
possibly other state information associated with web servers 46 to which the IP Proxy 



8 



WO 03/007183 PCT/CA02/01073 

system 18 may connect. It preferably stores state information about a connection that 
persists between discrete network packets, such as an HTTP request/response pair. 
The monitoring system 36 allows remote monitoring of the performance, efficiency, 
usage and health of an IP Proxy system 18 by an administrator through an interface 
5 such as a web browser 48. As its name implies, the logging system 38 may be 
configured to store usage, connection, user statistics and the like to the file system 40 
or some other secondary storage. 



Connections and Handlers 

■ 

10 The IP Proxy system 1 8 can preferably handle and process content from 

various information sources 20, including Internet-based sources. This functionality is 
provided by connection handlers, which are intermediate objects that have the ability to 
process content from inbound and outbound connections to an IP Proxy system 1 8. in 
the IP Proxy system 1 8 shown in Fig. 2, two such handlers, the TCP handler 24 and the 

15 HTTP handler 26, are shown. These handlers can preferably be replaced and 
customized or additional handlers can preferably be added to an IP Proxy system 18 as 
needed. The connection handlers can optimise not just the content but also the 
protocol. For example, some requests that would normally be sent to the mobile device 
(such as a request for a password) may be resolved by the connection handler, where 

20 requested data has been stored in the file system 40 or another store accessible to the 
connection handler, through the state persistence element 34, for example.. This 
instance of a protocol optimisation can adapt so-called "chatty" protocols to be more 
wireless friendly by reducing the amount of traffic sent over a wireless network to a 
mobile device, thereby reducing the effects of wireless network bandwidth constraints 
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and latency. 

Outbound connections would be made from mobile devices 1 2 in order to 
send data to and receive data from other entities such as Internet nodes. The IP Proxy 
system 18 preferably receives connection requests from mobile devices 12 using a 

5 particular protocol, such as a proprietary protocol called IP Proxy Protocol or IPPP 

« 

developed by the assignee of the present application. Other protocols might also be 
used. The IP Proxy system 18 then establishes an Internet connection, according to 
routing information provided by the mobile device 12, and translates and maps that 
connection to start forwarding data in both directions. A filtering or transcoding process 

10 is invoked whenever necessary, based on the type of content being passed over the 
connection, or based on a particular transcoding process specified in the connection 
request from the mobile device 12, for example. Such outbound connections will be 
described in further detail below, in the context of web browsing operations. 

Inbound connections are used, for example, to implement a data push 

1 5 model. In this model, a mobile device 1 2 may be sent information without having issued 
requests to fetch the information, as is the case with outbound connections. As 
described briefly above, mobile devices 12 may exist on a different network domain 
than Internet nodes. The IP Proxy system 1 8 is responsible for bridging the Internet and 
wireless network domains. Thus, the IP Proxy system 18 requires certain routing 

20 information to route the traffic to a particular mobile device 1 2. In a push operation, at 
least some of this routing information must be provided by the Internet node, such as 
the push server 42, that issues the request to establish an inbound connection. The IP 
Proxy system 1 8 may convert commonly known addressing schemes such as email or 
IP numbers into the appropriate wireless network address of an intended recipient 
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mobile device 12. In another embodiment, a transcoding process for pushed content 
may be selected and specified by a push server 12 or information source 20. 

Connection handlers in an IP Proxy system 1 8 are stream-based objects. 
When an outbound or inbound connection is requested, a virtual piped stream is 
5 established between mobile device 12 and the appropriate connection handler. The 
connection handler will be instantiated and started to process the content for the 
established connection. Loading the connection handler is based on a connection 
request, which preferably contains a reference to appropriate handler name that implies 
the type of the traffic that would normally go through the virtual piped stream and the 

10 location of the handler that must be loaded if is not already loaded. The functions of 
connection handlers include mapping Internet or other information source-side 
connections and mobile device-side connections, forwarding traffic between these 
connections, and loading and invoking the appropriate transcoders on information 
destined for a mobile device 1 2. 

1 5 Every connection is preferably associated with an instance of a connection 

handler. This is true even for a connection that does not require that content be 
processed by the IP Proxy system 18, such as a pure TCP connection between a 
mobile device 12 and a server. This type of connection handler forwards content back 
and forward without making any sort of modification to the content, although it may 

20 make modifications to the protocol. For clarity, those skilled in the art will appreciate the 
distinction between the data or content (what the mobile device requested or is being 
sent) and the protocol (the "wrappers" and conversions required to deliver the data). 

Connection handlers are also responsible for loading the appropriate 
content filters or transcoders. According to one embodiment, a connection handler such 
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as the HTTP connection handler 26 uses a particular transcoder in the transcoder 
system 28 specified by either the mobile device 12 or an information source such as 
push server 42 or web server 46. 

Fig. 3 is a flow chart representing general connection handler-related 
5 operations in an IP Proxy system. At step 50, the IP Proxy system 18 receives a 
connection request, which as described above may relate to an inbound connection or 
an outbound connection. When the connection is associated with a particular handler, 
such as an HTTP connection that requires HTTP connection handler 26, the 
appropriate handler is loaded and executed at step 54 and the connection is 

10 established, as indicated at step 58. If the request is outbound (from the mobile device 
1 2), then the dispatcher 22 examines the protocol type associated with the request and 
delegates the connection to the appropriate handler. Data may then be exchanged 
between a mobile device 1 2 and an Internet service, push server 42, web server 46 or 
other information source 20. 

15 If certain connection handlers are used for a connection, such as for a 

pure TCP connection as described above, then the data may pass through the IP Proxy 
system 18 unchanged. In some IP Proxy systems however, content sent over a TCP 
handler may be modified. When other connection handlers are used however, data 
destined for a mobile device 1 2 may need to be converted into a suitable format. Fig. 4 

20 is a flow chart of connection handler data processing operations. At step 62, data 
destined for a mobile device 12 is received. Although labelled as a response from a 
connection, following an information request from a mobile device 12, for example, it will 
be understood that data received by the connection handler may instead be information 
to be pushed to the mobile device 12 from a push server such as 42 via push service 
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30. The connection handler determines at step 64 if transcoding is required. If not, then 
the information is sent to the mobile device at step 70. Otherwise, the appropriate 
transcoder is loaded and executed as shown in step 66, and the data is transcoded into 
an acceptable format as shown in step 68, before being sent to the mobile device 1 2. 
5 In one embodiment, the entity that initiates the communication, the mobile device for 
fetched data or the push server 42 for pushed data, can specify a particular transcoder 
to do the transcoding of the fetched or pushed data, as described in more detail below. 

A connection handler may be implemented in computer software as a 
Java™ class file, placed in a certain directory in a file system such that an IP Proxy 

10 system Java Virtual Machine (VM) may locate and load the file when needed or 
requested. As those skilled in the art will appreciate, Java uses CLASSPATH 
environment variable as a guide to where it should perform a lookup for user defined 
classes. In one embodiment, the paths to connection handlers are among the first listed 
paths in the CLASSPATH so that they are loaded relatively quickly when requested. 

15 The connection direction (inbound or outbound) and the name associated with a 
connection handler may also play a role in defining the full class name of a handler. 
Another embodiment utilizes dynamic linked libraries (DLLs) or dynamic shared objects 
(DSOs) depending on the target operating system. 

Most connection handlers will normally be associated with a name that 

20 represents a protocol at the application layer. For example, if a mobile device 12 is 
enabled with a web browser and may therefore request to open connection to an 
Internet server such as 46, it would be appropriate to have HTTP as a name for that 
connection handler, illustratively HTTP connection handler 26. In one embodiment, the 
handler name adheres to the known rules of naming packages in Java language. 



13 



WO 03/007183 PCT/CA02/01073 

Preferably, the handler name is in lower case; however, from an IP Proxy system point 
of view, naming convention does not matter, provided the Java VM can load that 
connection handler. Any Connection Handler may also have its class name as 
Handler.class. An example of a valid full class name that represents a connection 
5 handler is as follows: 

net.rim.protocoI.iplayer.connection.handler.<connection direction>.<connection handler 

name>.Handler.class 

10 where connection direction can be either device, which implies outbound connection, or 
server, which implies inbound connection. Connection handler name is the name 
associated with the handler, for instance, http, ftp, etc. 

There are at least two ways that an information source such as an Internet 
node can establish a connection to a mobile device through the example IP Proxy 

15 system 18 shown in Fig. 2: (1) using a transportation layer protocol directly, such as 
TCP, to open a direct connection to the IP Proxy system 18, or (2) using a datagram 
protocol at the application layer, such as HTTP. The IP Proxy system 18 includes two 
corresponding connection handlers, which may, for example, represent a basic IP Proxy 
system that can process two of the most common types of connection. The first is the 

20 TCP connection handler 24, associated for example with the name tcp. The second is 
the HTTP connection handler 26, which may similarly be associated with the name http, 
as described above. In addition to supporting common connection types, these 
connection handlers may also satisfy requirements for Mobile Information Device Profile 
(MIDP) implementation at the mobile device 12. However, the IP Proxy system 18 and 

25 the mobile device 12 can be extended to support any other types of connections. In the 
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IP Proxy system 18, connection handlers may possibly be added by. providing an 
application programming interface (API) in the IP Proxy system 18 and developing new 
connection handlers that adhere to the API, for example. 

In one embodiment, the IP Proxy System 18 includes connection handlers 

5 that are loaded from a local storage medium, for example a disk drive associated with a 
computer on which IP Proxy system software is running. In another embodiment, the 
connection handler storage may also or instead be remote from the IP Proxy system 1 8, 
such as in a storage medium accessible by the IP Proxy system 18 through a LAN 
connection or even a WAN like the Internet. This allows sharing of a single directory of 

10 connection handlers among all IP Proxy systems 18 that can communicate with the 
connection handler store. It would also be possible to have third parties extend the 
connection handler set by embedding the URL where the connection handler java class 
can be found. 

If connected to the Internet, a connection handler directory could 
1 5 potentially be accessed and thus shared by all Internet-connected IP Proxy systems 1 8. 
Public Internet-connected connection handler directories would preferably receive 
connection handler requests from IP Proxy systems and in response transmit any 
requested connection handlers to the requesting IP Proxy system 1 8. A new connection 
handler may be required by an IP Proxy system 18 when a mobile device 12 which 
20 communicates with the IP Proxy system 18 downloads a new software application or 
invokes a new mobile device feature which uses a new connection scheme or a 
connection method that was not previously used by the mobile device 12. A mobile 
device user or the new application or feature may then send a control message to the 
IP Proxy system 18, indicating for example the name of the required connection 
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handler, perhaps the mobile device application that requires the new connection 
handler and an address associated with a connection handler directory from which the 
new connection handler may be requested. The IP Proxy system 18 would then 
preferably request the new connection handler from the directory. A connection handler 

5 directory could be implemented for example as a web server accessible to an IP Proxy 
system 18 using HTTP requests. 

When a connection handler is loaded from a remote source, the IP Proxy 
system 18 preferably stores the handler in a local store in order to provide for faster 
loading of the handler for subsequent operations involving the corresponding type of 

10 connection for either the mobile device 12 for which the connection handler was initially 
loaded from the directory or a different mobile device 12 supported by the IP Proxy 
system 18. Depending upon the memory resources available to an IP Proxy system 18, 
downloaded connection handlers may be stored indefinitely or for a particular period of 
time. Alternatively, a least recently used or LRU replacement scheme could be used to 

15 provide for more efficient use of available memory by overwriting relatively less 
frequently used connection handlers when new handlers are downloaded. Other 
memory management techniques could also be used to optimize local IP Proxy system 
connection handler storage arrangements. 



20 Transcoding 

Relative to computer networks such as the Internet, wireless 
communication networks are slow. Any program that bridges the two, as an IP Proxy 
system does, may have to transform Internet data so that it is formatted appropriately 
for a wireless network and mobile device. This process is referred to herein as filtering 
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or transcoding, and usually involves such operations as compressing data from the 
Internet into a more compact format appropriate for wireless transmission. 

In the following description, transcoding operations are illustrated primarily 
in the context of the above example of an HTTP handler 26 and HTTP connection. The 
5 HTTP connection and handler example is particularly useful in that HTTP allows 
content tags in the form of Multipurpose Internet Mail Extension (MIME) types, which 
may be used in some embodiments to determine an appropriate transcoderfor received 
information. 

In an IP Proxy system 1 8, there may be a single configuration file for each 
10 type of connection handler. In the IP Proxy system 18 for example, a single 
configuration file associated with the HTTP connection handler 26 may include 
information for all HTTP content transcoders. This configuration file is used to map 
transcoders to certain keys. The IP Proxy system 18 may consult this file to determine 
which content transcoders are available to manipulate any received content destined for 
15 a mobile device 12. 

In the configuration file, general rules are preferably specified for how to 
define the mapping between content types and transcoders. One example of a possible 
configuration file entry is as follows: 

20 Entry = {[default] : { RSV | <Transcoder name>}} | 

{ [[ InputType] | < ->OutputType> ] : [ Transcoder name] } 

where 

default indicates to the IP Proxy system which default transcoder should 
be loaded in case there is no one transcoder associated with a received content type or 
25 connection request; 
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RSV is a set of reserved keywords that is used in configuration file, such 
as pass (i.e. forward data to the mobile device without transcoding) or discard (i.e. do 
not transcode or forward data to the mobile device); 

Transcoder name is the name of the mapped transcoder; 
5 InputType indicates the input content type that the mapped transcoder can 

accept, which for an HTTP transcoder configuration file may be a MIME type; and 

OutputType indicates the output type, such as a MIME type for an HTTP 
transcoder that the transcoder can produce. 

By using a content transcoder configuration file, newtranscoders may be 
1 o added for use by an IP Proxy system 1 8. Therefore, as new transcoders are developed 
and become available, they can be added to the configuration file for any appropriate 
connection handlers and can thereafter be loaded by a connection handler when' 
required, and without affecting other components of the IP Proxy system 18. For 
example, configuration file entries may be added without shutting down the entire IP 
15 Proxy system 18, thus allowing dynamic expansion of data that can be converted for 
transmission to mobile devices 12. 

In another embodiment, a common configuration file format for all 
connection handlers is used, and thus only a single configuration file entry need be 
prepared and can be added to the configuration file for any connection handler. The 
20 concept of a common configuration file format for all connection handlers can be further 
extended to providing a single configuration file for an IP Proxy system 18. Such a 
configuration file could then be used by all connection handlers in the IP Proxy system 
18 to determine which content transcoders are available and to select a particular 
transcoder for received content. However, it should be understood that a common 
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configuration file format is in no way required. Some connection handlers may share a 
configuration file entry format or even a single configuration file, whereas others 
supported by the same IP Proxy system 18 may have different configuration files and 
entry formats. 

5 The IP Proxy system 18 preferably loads and executes a particular 

transcoder specified by either a mobile device or an information source to transcode 
data being either pushed to or pulled by a mobile device 1 2. Several illustrative example 
content transcoder loading control schemes are described in further detail below. 
Although these examples relate primarily to HTTP connections and handlers, other 

1 o connection types and handlers may use similar arrangements and methods to select a 
transcoder. 

It should also be appreciated that a transcoder may instead be selected 
based upon information other than content types, including information in a header 
portion or other portion of a connection request from a mobile device, a response to a 

15 connection request, or a communication from an information source including 
information to be pushed to a mobile device. For example, an IP Proxy system 18 may 
be configured to determine a type of the mobile device 12 to which data is to be sent. 
Transcoder selection by the IP Proxy system 18 could similarly be based on a network 
address or other identifier of the mobile device 12. Mobile device- or device type- 

20 dependent transcoder selection schemes may be supported by providing a device or 
device type mapping table accessible to the IP Proxy system 18, which maps devices or 
device types to transcoders. Alternatively, a configuration file may be adapted to 
include device or device type identifiers to thereby associate particular transcoders with 
devices or device types. 
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In a similar manner, transcoders may be selected based on an address 
(such as a URL) or other identifier of an information source, to enable information 
source-specific transcoding. A mapping table or a configuration file accessible to an IP 
Proxy system such as 18, may be used to enable transcoder selection based on 
5 information source. This type of transcoder selection may be useful, for example, when 
a particular transcoder is to be used to transcode any content that originates from a 
specific website and is destined for a mobile device. 

Although the primary type of transcoder selection scheme described 
below is based on a particular transcoder specified by a mobile device or information 
10 source, any of these alternative schemes may be used to select a transcoder, for 
example, when a specified transcoder is not available. If information content to be sent 
to a mobile device includes multiple content types, then these schemes may also be 
used to select a transcoder for one or more of the multiple content types. 

15 Specifying a Content Transcoder from a Mobile Device 

A connection request from a mobile device 12 may specify that a 
particular transcoder be used to transcode any content received in response to the 
request. For an HTTP connection for example, an IP Proxy system 18 may be 
configured to expect a Content-Transcoder field in an HTTP request header to indicate 

20 that a mobile device 1 2, or typically an application on the mobile device 1 2, is specifying 
a particular HTTP content transcoder. The IP Proxy system 1 8 will load and execute the 
specified transcoder to manipulate any response to the request. The active connection 
handler in the IP Proxy systerp 1 8, the HTTP connection handler 26, may also modify 
the request to include an indication, such as a MIME type, of the type of content that 
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can be accepted in response to the request. The Content-Transcoder header field 
should have a value that is valid in the context of the HTTP configuration file, or where 
another connection handler is used, its corresponding configuration file. 

If a requested transcoder is not available, then an error message will 

5 preferably be sent back to mobile device 1 2, for example in the form of an lOException 
indicating that the requested transcoder is not available. The mobile device application 
or user may then have the option to retry the request with a different transcoder. When 
the requested information is intended for a mobile device software application that 
requires information in a particular format available only from the specified transcoder 

10 however, the request may instead be retried at a later time when the specified 
transcoder may possibly be available. 

Transcoder selection in a mobile device information request will now be 
described in further detail by way of several illustrative examples of HTTP requests. Fig. 
5 is a signal flow diagram illustrating an example of mobile device-controlled transcoder 

15 selection for an HTTP connection. Although Fig. 5 shows only those components of the 
IP Proxy system 18 directly involved in the example of an HTTP request from a mobile 
device 1 2, other system components may also be present. In order to avoid congestion 
in the drawings however, such components as 30 through 48 in Fig. 2 have not been 
shown in Fig. 5. 

20 In Fig. 5, an HTTP request is sent from the mobile device 12, through a 

wireless network and possibly through a WAN and appropriate gateway to the IP Proxy 
system 18. As described above, the mobile device 12 may communicate with an IP 
Proxy system 18 using a protocol other than HTTP, such as the proprietary IPPP. In 
such arrangements, although the connection request conforms to a particular protocol, 
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the request may specify a connection type or connection handler, HTTP in this 
example, associated with a different protocol. Therefore, references to HTTP requests • 
sent from a mobile device 12 should be interpreted to include both HTTP requests, if 
mobile device to IP Proxy system communications are via HTTP, as well as connection 

5 requests which conform to other protocols but specify HTTP or HTTP connection 
handlers and thus are interpreted by an IP Proxy system 18 as HTTP requests. • 

The request from the mobile device 1 2 is received by the dispatcher 22, 
which interprets the request as an HTTP request and loads the HTTP handler 26. 
Preferably in a header field, such as the Cbntent-Transcoder field referred to above, the 

10 request in this example specifies that a particular transcoder which converts from 
Wireless Markup Language (WML) content to a tokenized, compressed version of WML 
generally referred to as Compiled WML or simply WMLC, should be used to transcode 
any content received in response to the request. The request may also include an 
indication of the type of content, WMLC in Fig. 5, that the mobile device is configured to 

15 accept. Since the IP Proxy system 18 may determine or infer the content type(s) 
accepted by the mobile device 12 from the output type of the specified transcoder, 
accepted content types need not necessarily be specified in the request from the mobile 
device 12. 

The example request shown in Fig. 5 specifies the particular transcoder in 
20 terms of its input content type (WML) and output content type (WMLC). However, other 
transcoder naming conventions are also possible. When a configuration file (72 in Fig. 
5) has entries in a format as described above, part of the file entry for each transcoder 
indicates its respective input and output content types. The "Transcoder Name" field in 
such a configuration file entry therefore need not necessarily also include the input and 
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output content types. Although many different transcoder naming schemes are possible, 
a particular transcoder is preferably specified in any mobile device requests and 
configuration files using the same name. 

Regardless of the transcoder naming scheme, the HTTP handler 26 
5 preferably uses the specified transcoder name, WML->WMLC in Fig. 5, to perform a 
lookup in the configuration file 72, shown in the transcoding system 28. It should be 
appreciated however, that the configuration file 72 might instead be external to the 
transcoding system 28, part of the HTTP handler 26, or even external to the IP Proxy 
system 18 provided that the HTTP handler 26 can access the file. In most 

1 o implementations, the configuration file 72 will be stored in a data store accessible by the 
IP Proxy system 18, typically on the same computer system on which the IP Proxy 
system 18 is running. 

• The HTTP handler 26 searches the configuration file 72 to determine if the 
transcoder specified in the request is available in the IP Proxy system 18. Where the 

1 5 transcoder input content type is not inferable from the transcoder name or specified in 
the request from the mobile device 1 2 as in Fig. 5, the transcoder input content type is 
preferably available from the configuration file 72. In Fig. 5, the configuration file 72, 
which may, for example, be implemented as a lookup table, includes entries for two 
transcoders, the specified WML->WMLC transcoder and an HTML->WMLC transcoder. 

20 Since the WML->WMLC transcoder specified in the mobile device request has an entry 
in the configuration file 72 and is therefore available to the IP Proxy system 18, the 
HTTP handler 26 prepares an HTTP request including the input content type of the 
transcoder, WML, as an accepted content type and submits the HTTP request to the 
web server 76. If the specified transcoder is not available in the IP Proxy system 18, 
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then the HTTP handler 26 returns an error message to the mobile device 12, through 
the dispatcher 22 or other protocol translator if necessary, indicating that the required 
transcoder is not available. Alternatively, the dispatcher 22 may perform the 
configuration file lookup operation and return the error message to the mobile device 
5 .12. 

In response to an HTTP request from the IP Proxy system 18, the web 
server 76 returns requested content, in WML format in the example in Fig. 5, to the IP 
Proxy system 18. The HTTP handler 26 then determines that the returned content is 
WML, loads the WML->WMLC transcoder 74 specified in the mobile device request 

10 from a local store for example, and executes the transcoder to convert the received 
content into WMLC. The WMLC content is then fo warded to the mobile device 12, 
through the dispatcher 22. 

Although Fig. 5 shows the response to the mobile device 12 being 
handled by the dispatcher 22, similar protocol translation or conversion between HTTP 

15 used by the handier 26 and a communication protocol used by the mobile device 12 
may instead be performed by the HTTP handler 26 or another protocol 
translation/conversion module in the IP Proxy system 18. 

In the event that content is returned to the IP Proxy system 18 in other 
than the requested content type, an error message is preferably returned to the mobile 

20 device 12 and possibly the information source, web server 76, indicating that the 
request could not be completed as specified. Alternatively, if the returned content 
cannot be converted using the specified transcoder, then the HTTP handler 26 may 
search for a transcoder to transcode the received content into a content type that can 
be transcoded by the requested transcoder. The default transcoder or a different 
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transcoder having an input content type and an output content type respectively 
corresponding to the received content type and the content type accepted by the mobile 
device 12 may instead be used. When content is returned in the mobile device- 
acceptable format, WMLC in the example of Fig. 5, the content may be forwarded to the 
5 dispatcher 22 without transcoding. Any time the specified transcoder could not be used 
to transcode returned content, however, the mobile device 12 is preferably informed 
that the request was not completed as specified, and possibly which transcoder was 
used instead of the specified transcoder. 

Since the mobile device 12 specifies a particular transcoder to be used to 

1 o transcode content returned from an information source in response to a request, control 
of any subsequent transcoding operations when the specified transcoder is not 
available may also be passed to the mobile device 12. For example, when the 
transcoder configuration file 72 does not include an entry for the specified WML- 
>WMLC transcoder or the returned content is not of the transcoder's input content type, 

15 the I P Proxy system 1 8 may send a message to the mobile device 1 2 indicating that the 
specified transcoder is not available or cannot be used; The mobile device 1 2, a mobile 
device software application associated with the request, or a mobile device user may 
then respond to the message indicating the action to be taken. This action may include, 
for example, forwarding the content to the mobile device 12 without transcoding, 

20 invoking the default transcoder, invoking a different particular transcoder specified by 
the mobile device 12, software application or user, or discarding the content. The IP 
Proxy system 1 8 may also determine which if any of the transcoders with corresponding 
entries in the configuration file 72 may transcode the received content into either the 
output content type of the transcoder specified in the request or other content types, 
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and identify such available transcoders in the message sent to the mobile device 12. 
The mobile device 12, software application or user may then use this information to 
determine if any of the available transcoders should be used to transcode the received 
content. For instance, if returned content cannot be transcoded by the specified 

5 transcoder into a format required for particular processing operations at the mobile 
device 1 2, but a second transcoder is available to. transcode the returned content into a 
content type that can be viewed on the mobile device 1 2, then a user may specify that 
the returned content should be transcoded using the second transcoder and the 
transcoded content should be forwarded to the mobile device 1 2. Although the originally 

10 intended processing operations might not be possible using content that was 
transcoded using the second transcoder, the user is able to at least view the content. 

In order to avoid sending connection requests that specify unavailable 
transcoders, it may be desirable for the mobile device 1 2 to query the IP Proxy system 
1 8 for a list of available transcoders prior to issuing a connection request. A connection 

1 5 request can then be prepared using one of the transcoders known to be available to the 
IP Proxy system 1 8. If a required transcoder is not available at an IP Proxy system 1 8, 
then the mobile device 12 may query other IP Proxy systems in an attempt to find the 
required transcoder, prepare a connection request specifying an alternate but available 
transcoder or abort an information request operation involving the required transcoder. 

20 It is. contemplated that a specified transcoder may, for example, be 

associated with a particular mobile device software application or function and therefore 
is configured to output content in a form required by the software application. The 
content types output by such transcoders may be common types, such as WMLC in the 
above example, but may be adapted to certain displays, software application input 
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formats or software application- or mobile device-related attributes. As such, a default 
or other transcoding operation may not produce content in a format usable by the 
mobile device software application, and an IP Proxy system 18 may therefore be 
configured to abort processing of a request or to discard content returned from an 

5 information source if the specified transcoder is not available. Such subsequent 
processing may be controlled by the mobile device 12, a mobile device software 
application or a mobile device user, as described above. 

In the example shown in Fig. 5, the transcoder configuration file 72 
includes entries for "mutually exclusive" transcoders, in the sense that the output 

10 content type of each transcoder is not compatible with an input type of any other 
transcoder. In one embodiment, one or more further transcoders may be used to 
convert received content into a format or type that may be accepted by the specified 
transcoder. The request sent by the IP Proxy system 18 to the information source, 
illustratively web server 76, may then be formatted to extend the accepted content types 

15 to include the input content types of any of the further transcoders as accepted content 
types. 

Fig. 6 is a signal flow diagram representing mobile device-controlled 
transcoder selection with extension of accepted content types. As in Fig. 5, Fig. 6 shows 
only those components of the IP Proxy system 1 8 directly involved in an HTTP request 
20 from a mobile device 12 in order to avoid congestion in the drawings. 

An HTTP request specifying a particular transcoder and an accepted 
content type is sent from the mobile device 12 to the IP Proxy system 18, possibly 
through one or more intervening networks and interface components. As in the above 
example, the request is received by the dispatcher 22, which interprets the request as 
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an HTTP request and loads the HTTP handler 26. The HTTP handler 26 then consults 
the configuration file 78, searching not only for the specified transcoder name, but also 
for entries associated with any transcoders that output content types that may be input 
to the specified transcoder. Therefore, according to this embodiment, additional MIME 

5 types are appended to the header Accept line of an HTTP request based not only on 
the specified transcoder input type, but also on input types for other transcoders. In Fig. 
6 for example, the HTTP handler 26, perhaps in a first search pass through the 
configuration file 78, finds the specified WML->WMLC transcoder entry. The HTTP 
handler 26 may then repeat the configuration file search for any transcoders such as 

10 the HTML->WML transcoder that convert content into WML, which can be input to the 
specified WML->WMLC transcoder, to thereby identify further content types that may 
be accepted in response to the request. A chained transcoder 82 that converts HTML 
to WMLC may also be created from the HTML->WML and WML->WMLC transcoders. 
The HTML->WML and WML->WMLC transcoders may also be separately invoked. The 

15 configuration file search may be further repeated by the HTTP handler 26, depending 
for example on acceptable delays in HTTP request processing. 

In order to avoid the delays and demand on processing resources 
associated with such multiple search passes through a configuration file 78, a 
transcoder content type lookup table is may be used. When transcoders are first 

20 installed in an IP Proxy system 18, a comprehensive mapping table is preferably 
constructed to map received content types to possible output content types. For 
example, in Fig. 6, a lookup table entry for the input content type of the specified 
transcoder, WML in Fig. 6, would indicate that HTML can be converted into WML. The 
table might instead be organized into single- and chained-transcoding sections, 
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whereby if only a single transcoding operation is preferred, the single-transcoder part of 
the table including an entry for the specified WML-> WMLC transcoder would be 
accessed. If further transcoding operations and the associated processing operations 
and time delays are acceptable, then the HTTP handler 26 may perform a lookup of the 
5 input content type of the specified transcoder in a chained-transcoder section of the 
table. Preferably, the format of the transcoding configuration file may be adapted to 
represent just such a lookup table in order to speed up the search. This may be 
accomplished, for example, by specifying a path between content types involving 
multiple transcoders. 

10 The determination regarding whether or not multiple transcoding 

operations will be permitted may be made by the HTTP handler 26 either before or after 
the table or configuration file lookup operation is performed, before an HTTP request is 
sent to the web server 80, or even after the requested content is received from the web 
server 80. In the example of Fig. 6, it is assumed for illustrative purposes that multiple 

15 transcoders may be invoked. The Accept line in the header of the HTTP request from 
the mobile device 12 is therefore expanded by the system 18 to include HTML in 
addition to WML. As described above, the accepted formats are preferably listed in 
order of preference. Since HTML requires two transcoding operations instead of the 
single transcoding operation of the specified transcoder, WML is preferably listed before 

20 HTML in the Accept line of the HTTP request sent from the IP Proxy system 18 to the 
web server 80. It is also feasible for the chain of transcoders to include both local and 
remote transcoding services. These remote transcoding services could be transcoder 
files that the IP Proxy system 1 8 discovers, downloads and executes or they could be 
external transcoding services which receive data in one format and return it in another. 
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The web server 80 then returns the requested content, in HTML format in 
the example in Fig. 6, to the IP Proxy system 1 8 in response to the HTTP request. The 
HTTP handler 26 determines that the returned content is HTML, loads and executes the 
HTML->WML transcoder and then loads and executes the specified WML->WMLC 

5 transcoder on the WML result of the first transcoding operation. The resultant WMLC 
content is then forwarded to the dispatcher 22 and then to the mobile device 1 2. When 
WML content is returned by the web server 80, only the WML->WMLC transcoder 
would be invoked. In the event that the specified transcoder is not available or the 
returned content is not one of the accepted content types specified in the request from 

10 the IP Proxy system 18, request processing may either be aborted or proceed as 
described above. 

A determination to allow or deny multiple transcoding operations may be 
based upon predetermined criteria such as maximum HTTP request processing time or 
maximum content transcoding time or processor time for example. This determination 

15 might also take a mobile device user-specified priority into account. If high time priority 
(low time delay) is assigned by the user to a submitted request, then single transcoder 
operations may be selected. Alternatively, if a high data priority is associated with a 
request, then any number of chained transcoder operations may be allowed in order to 
get the requested data back to the mobile device in an acceptable format. Multiple 

20 transcoders may also be specified in the information request from the mobile device. 
Other criteria which may be applied by a connection handler include but are in no way 
limited to allowing chained transcoders only for relatively small amounts of received 
content, only at certain times of day, under specific current traffic conditions, or only 
when the configuration file or lookup table is stored in a local file system. Further or 
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alternate criteria may be apparent to those skilled in the art and as such remain within 
the scope of the present invention. 

It is also possible that more than one multiple-transcoder chain may be 
available to convert between any two content types. In such situations, the IP Proxy 
5 System uses a priority scheme, based for example on transcoding cost or fidelity, to 
select between several available chains. 

Specifying a Content Transcoder from an Information Source 

A server or information push operation differs from information 

10 request/response operations in that an information source sends content to a mobile 
device 12 without first receiving a request to do so. Similar to the HTTP operations 
described above however, a particular transcoder may be specified by an information 
source attempting to push content to a mobile device 1 2. Fig. 7 is a signal flow diagram 
of an example of server-controlled transcoder selection for an HTTP operation. As 

15 . above, Fig. 7 shows only those components of the IP Proxy system directly involved in 
an HTTP-based server push. 

In Fig. 7, content is pushed from the push server 42 to the IP Proxy 
system 1 8. For an HTTP-based operation, the push may be an HTTP post operation, in 
which the push server 42 submits a post request to the IP Proxy system 18. The post 

20 request, similar to the HTTP request described above, encloses header fields in which 
at least a transcoder name (WML->WMLC in this example) and possibly an indication 
of the type of content, such as a MIME type of WML in Fig. 7, may be specified. Since 
the content is provided by the same entity that selects the particular transcoder, the 
content type will normally be compatible with the specified transcoder and therefore 
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need not necessarily be specified in the post request. 

The post request from the push server 42 is received by the push services 
module 30. In the example of Fig. 7, the push operation is HTTP-based, and the push 
services module 30 therefore invokes the HTTP handler 26. It should be appreciated 
5 that different push services may be associated with respective handlers in an IP Proxy 
system 18, and that a single IP Proxy system 18 may provide several different push 
services. It is also contemplated that multiple push services modules may be associated 
with a single connection handler. Alternatively, a single push services module may be 
functionally similar to the dispatcher 22 and provide an interface between a push server 
1 o 42 and any handler in an IP Proxy system 1 8. For the purposes of clarity however, only 
a single push services module 30 associated with the HTTP handler 26 is shown in Fig. 
7. 

The HTTP handler 26 preferably uses the transcoder name in the post 
request, WML->WMLC in Fig. 7, to perform a lookup in the configuration file 72 to 

15 determine if the specified transcoder is available in the IP Proxy system 18. As in the 
preceding embodiments, a particular transcoder is preferably specified in any post 
requests and transcoder configuration files using the same name. In Fig. 7, an entry for 
the transcoder specified in the post request exists in the configuration file 72. The WML- 
>WMLC transcoder 74 is therefore available to the IP Proxy system 18, and the 

20 transcoder 74 is loaded and executed to transcode the WML content enclosed in the 
post request into WMLC content. The WMLC content is forwarded to the mobile device 
1 2, through the dispatcher 22. When content is provided by a push server in a mobile 
device-acceptable format, WMLC in the example of Fig. 7, the post request may specify 
a null or other predetermined value in an appropriate request header field to specify that 
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the content should be forwarded to the dispatcher 22 without transcoding. It is also 
contemplated that a push services module 30 may be configured to directly manage the 
transcoding of pushed content, instead of invoking a separate connection handler. 

If the particular transcoder specified in the post request from the push 
5 server 42 is not available to the IP Proxy system 18, then the push operation may be 
aborted. Alternatively, a different transcoder having an input content type and output 
content type respectively compatible with the content from the post request and a 
content type accepted by the mobile device 1 2, if known to the IP Proxy system 1 8, may 
be used. Any time the requested transcoder could not be used to transcode pushed 

10 content, a push operation failure or error message may be returned to the push server 
42, particularly if the push server 42 is configured to retry undelivered content. When 
the default or any other transcoder is used instead of the specified transcoder, then the 
push server 42 may be informed of the particular transcoder that was used. Any such 
alternate transcoding operations may instead be controlled by the push server 42, which 

15 may, for example, specify another transcoder name in response to a push operation 
failure or error indication message returned by the IP Proxy system 1 8. Since pushed 
content was not requested by the mobile device 12, no such error or failure message 
would typically be sent to the mobile device 12. 

If the transcoder specified by a push server 42 is associated with a 

20 particular mobile device software application or function or configured to output content 
in an application-specific format for example, then alternate transcoders might not 
produce content in a format usable by the mobile device application. As described 
above however, a second transcoder may be available to transcode the content from 
the push server 42 into a content type that can at least be processed in a certain way, 
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to be displayed on the mobile device 12, for example. In response to an error or failure 
message from the IP Proxy system 18, the push server 42 may re-submit the content 
and/or specify the second transcoder. The pushed content, although not suitable to be 
processed on the mobile device as originally intended, may thereby be viewed on the 
5 mobile device 12. The push server 42 may also set a transcoder substitution policy, 
such as no transcoder substitutions allowed, chained transcoders allowed, etc. 

The signal flow diagram of Fig. 7 shows a single content transcoder in a 
server data push via an HTTP post operation. It should be apparent that a server may 
specify more than one content transcoder, to be used for example in a chained 
10 transcoding operation. 

External Transcoder Systems 

As described briefly above, transcoders may be loaded as needed from a 
local store on a computer system on which an IP Proxy system 18 has been 

15 implemented. In another embodiment, transcoders may also be loaded from an external 
store. Fig. 8 is a general block diagram of a communication system with an external 
transcoder system. 

The system 90 shown in Fig. 8 is similar to system 1 0 of Fig. 1 , except for 
the external transcoder system 86. Elements common to both systems 1 0 and 90 have 

20 been described above and are therefore described only briefly. As shown by the dashed 
lines in Fig. 8, the IP Proxy system 84 may communicate with the transcoder system 86 
through some sort of direct connection such as a serial port or connection, through a 
WAN 16 such as the Internet, or through a LAN 88 within which the IP Proxy system 84 
and the transcoder system 86 are configured to operate. Other communication links 
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between the IP Proxy 84 and the transcoder system 86 will be apparent to those skilled 
in the art. 

Fig. 9 is a signal flow diagram illustrating an example of mobile device- 
controlled transcoder selection for an HTTP connection with an external transcoder 
5 system such as shown in Fig. 8. As in the preceding examples, an HTTP request is sent 
from the mobile device 12 to the IP Proxy system 84, specifying a particular transcoder 
(WML->WMLC) and possibly indicating the content type, WMLC in this example, that 
can be accepted at the mobile device 12. The request is received by the dispatcher 22 
in the IP Proxy system 84, which determines that the request is an HTTP request and 

10 thus forwards the request to the HTTP connection handler 94, The HTTP handler 94 
may be substantially similar to the HTTP handler 26 in Fig. 2 for example, although it 
operates somewhat differently than handler 24 to load content transcoders. The HTTP 
handler 94 receives the HTTP request from the mobile device 1 2 and may then refer to 
a transcoder configuration file 92 or a lookup table as described above to determine 

15 whether or not the specified WML->WMLC transcoder is available to convert content 
received in response to the request. If an entry corresponding to the specified 
transcoder is found in the configuration file 92 or lookup table, then the HTTP handler 
94 sends a request to the appropriate information source such as web server 76. Web 
server 76 processes the request from the IP Proxy system 84 and returns WML content 

20 to the HTTP handler 94. These operations are substantially as described above in the 
preceding examples. 

When the WML content is received by the HTTP handler 94, it is 
preferably stored in a file system or other data store 98 while the appropriate transcoder 
is loaded. In the example of Fig. 8, the HTTP handler 94 requests the specified WML- 
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>WMLC transcoder from the transcoder system 86. Although this request is shown in 
Fig. 8 as an HTTP request from the HTTP handler 94, it should be apparent that other 
transfer mechanisms might instead be used by an IP Proxy system 84 to retrieve a 
transcoder from a remote transcoder system. For example, if the IP Proxy system 84 
5 communicates with the transcoder system 86 via a LAN 88 (Fig. 7), then a LAN protocol 
or data access and transfer scheme could be invoked by the HTTP handler 94 in order 
to retrieve any required transcoders. In Fig. 8, the transcoder system 86 Ideates the 
requested WML->WMLC transcoder among its available transcoders 96 and returns the 
requested transcoder to the IP Proxy system 84. 

1 o Regardless of the particular transcoder transfer mechanism implemented, 

the IP Proxy system 84, or in the example of Fig. 8 the HTTP handler 94, receives and 
executes the returned WML->WMLC transcoder, as indicated at 100. The previously 
received and possibly stored WML content may then be processed by the transcoder 
1 00 to transcode the WML content, and a response containing the transcoded content 

1 5 is returned to the mobile device 1 2 by the dispatcher 22. 

If chained transcoder operations are specified in the connection request 
from the mobile device 1 2, then more than one transcoder request may be made by the 
IP Proxy system 84 to the transcoder system 86. Multiple transcoders may instead be 
requested in a single request to the transcoder system 86. Processing of previously 

20 received content for chained transcoder operations may proceed either as each 
required transcoder is loaded by the IP Proxy system 84, with intermediate transcoded 
content possibly being stored in a file system or data store such as 98, or only when all 
required transcoders have been loaded. An IP Proxy system 84 may also extend the 
Accept line in an HTTP request sent to an information source if any of the transcoders 
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available from an external transcoder system can transcode other content types into the 
input content type of the specified transcoder, as described above in conjunction with 
Fig. 6. 

When a transcoding operation is complete, a transcoder loaded from the 

5 external system 86 is preferably stored locally by the IP Proxy system 84 in order to 
avoid subsequent requests to the external transcoder system 86 for the same 
transcoder. Retrieval and loading of a transcoder from a local or internal store in the IP 
Proxy system 84 will typically be completed much faster than a request to a remote 
system and reduces traffic on the communication link between the IP Proxy system 84 

1 o and the transcoder system 86. In such I P Proxy systems, the active connection handler, 
which is the HTTP handler 94 in Fig. 8, preferably determines if a required transcoder is 
stored in a local data store before requesting the transcoder from the external 
transcoder system 86. Depending upon the amount of available storage, transcoders 
may be stored indefinitely or for a certain predetermined period of time. Other memory 

15 management schemes, such as over-writing stored transcoders on an LRU basis for 
example, may also be used when memory resources are limited. 

The configuration file 92 or transcoder lookup table may be adapted for 
external transcoder loading by including an indication of the location of a transcoder in 
the configuration file or table entry for the transcoder. The file 92 or table is preferably 

20 updated if a transcoder is stored to, or overwritten in, a local memory, such that the 
active handler can determine from the initial lookup operation whether or not the 
transcoder must be loaded from the external transcoder system 86. When a transcoder 
has not been or is no longer stored locally, then the file 92 or lookup table preferably 
indicates from where the transcoder may be retrieved. For a transcoder that may be 
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retrieved through an HTTP connection, the corresponding file or table entry may 
indicate the IP address of the transcoder system 86, whereas a network address may 
be specified in the configuration file or lookup table when a LAN connection is used. If 
. the location of a transcoder system from which a specified transcoder is available is 
5 known to a mobile device 12 or a mobile device user, then the location may also or 
instead be included in the connection request from the mobile device. 

It is also contemplated that more than one external transcoder system 
may be implemented in a communication system such as 90. In such an arrangement, 
the configuration file 92 or lookup table would preferably include entries for all 

10 transcoders that are available to an IP Proxy system 84 through all of the external 
transcoder systems with which it can communicate. An IP Proxy system 84 may thereby 
download transcoders from any of a number of transcoder systems via direct or network 
connections. Overall operation of an IP Proxy system 84 with multiple transcoder 
systems would be substantially as described above, except that different transcoder 

15 systems may be accessed, possibly using different transfer mechanisms and 
communication protocols, for each data transcoding operation. Chained transcoding 
operations may also potentially involve communication with different transcoder 
systems. • 

The configuration file 92 or lookup table are preferably arranged to 
20 facilitate a simple resolution scheme when a particular type of transcoder is available 
from more than one transcoder system. Although an IP Proxy system 84 may be able to 
access multiple transcoder systems, an owner or administrator of an IP Proxy system 
84 may designate one of these transcoder systems as a preferred or default system 
from which the IP Proxy 84 system first attempts to download a transcoder. The order of 
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preference of transcoder systems for any transcoder available from more than one 
transcoder system may for example be reflected in the order of configuration file or 
lookup table entries. If the file or table is arranged by transcoder type, then entries 
corresponding to the most preferred sources for a particular transcoder are preferably 
5 listed before entries associated with other transcoder systems. The configuration file or 
lookup table may instead be arranged according to transcoder system, with all entries 
for the default or preferred transcoder system occurring first. A preferred transcoder 
system might also be specified in a connection request from the mobile device 12. In 
these example arrangements, an IP Proxy system 84 will preferably attempt to load a 

10 particular transcoder from a preferred source before accessing any other sources. 

It should be apparent from the foregoing description that if the specified 
transcoder could not be loaded by an IP Proxy system 84, then an error message may 
be returned to the mobile device 1 2 and possibly the web server 76. Any of the error or 
failure operations described above may be performed by the IP Proxy system 84 and 

15 mobile device 12 if the specified transcoder could not be used to transcode received 
content. 

A data push operation from a push server such as 42 may proceed in a 
similar manner and therefore will be described only briefly. A push services module 
may either invoke an appropriate connection handler to process a push request from a 
20 push server or possibly be configured to process the request directly. Any transcoder(s) 
specified in the push request would then be downloaded by the active connection 
handler or possibly another connection handler, if required, from the external transcoder 
system 86 or a further transcoder system specified in the push request. Once 
downloaded to the IP Proxy system 84, the specified transcoder is invoked to process 
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the content enclosed in the push request. The transcoded content may then be pushed 
to an intended destination mobile device 12 through the dispatcher 22 if any protocol 
translation is necessary. This type of push operation is thus substantially the same as 
described above with reference to Fig. 7 except that the specified transcoder (or 
5 transcoders if chained transcoder operations are specified in or allowed for the push 
request) is downloaded from an external transcoder system. Downloaded transcoders 
may be stored by an IP Proxy system 84 in a local store in order to avoid subsequent 
downloading of the same transcoders. Any of the above failure or error processing 
schemes may also apply to data push operations. 

10 Fig. 10 shows a further signal flow diagram for an external transcoder 

system. In Fig. 10, not only the transcoder system 86, but also the configuration file 
1 02 is external to the IP Proxy system 84 and therefore may be shared among multiple 
IP Proxy systems. Communications between an IP Proxy system 84 and the 
configuration file 102 may be via a direct connection or a network connection, and may 

1 5 be different for different IP Proxy systems. For example, the configuration file 1 02 may 
be maintained by an owner or operator of a particular IP Proxy system 84 which is 
linked to the configuration file by a direct communication link, whereas other IP Proxy 
systems may communicate with the configuration file 102 through local or wide area 
network connections. The configuration file 102 might also be maintained at the 

20 transcoder system 86. As above, the configuration file 1 02 may be implemented as a 
lookup table. The configuration file 102 may thus be considered a registry, with which 
one or more external transcoder systems such as 86 register available transcoders. 

When an HTTP request specifying a particular transcoder is received by 
the dispatcher 22 in the IP Proxy system 84, it is forwarded to the HTTP handler 94, 
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which as described above determines if the specified transcoder is available in the IP 
Proxy system 84. In the example of Fig. 1 0 however, the configuration file 1 02 is remote 
from the IP Proxy system 84. If the configuration file 102 is accessible via HTTP, then 
the HTTP handler 94 manages the transcoder lookup function with the configuration file 

5 102. If the configuration file 102 is not adapted for HTTP, then a different connection 
handler may be invoked to facilitate the transcoder lookup or configuration file search. 

Depending upon the transcoders available to the IP Proxy system 84, the 
HTTP handler 94 may include both the input content type of the specified transcoder, 
WML in this example, and any additional content types which may be transcoded into 

10 the input content type of the specified transcoder as accepted content types in the 
request to the information source, illustratively web server 76. The request from the IP 
Proxy system 84 to the web server 76 therefore includes not only WML but also HTML 
as accepted content types, since HTML can be transcoded into WML by the HTML- 
>WML transcoder 104b, which has a corresponding entry in configuration file 102. 

15 Either of these content types can ultimately be processed by the specified WML- 
>WMLC transcoder. 

As above, it is assumed that the web. server 76 from which content is 
requested returns WML content to the HTTP handler 94. The transcoding system 86 in 
the example shown in Fig. 10 includes a set of remotely executable transcoders 104, 

20 comprising a WML->WMLC transcoder 104a and an HTML->WML transcoder 104b, 
and thereby enables remote transcoding of content. Instead of requesting and loading 
the WML->WMLC content transcoder 1 04a from the transcoder system 86, the HTTP 
handler 94 (or another connection handler, depending on the particular transcoder 
system and the transfer schemes it supports) transfers the WML content to the 
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transcoding system 86. Within the transcoding system 86, the appropriate WML- 
>WMLC transcoder 104a is executed and the WML content is transcoded into WMLC 
format. The WMLC content is then returned to the HTTP handler 94, or to another 
connection handler if IP Proxy system 84 to transcoder system 86 communications do 
5 not use HTTP. When the WMLC content is returned by the transcoding system 86 and 
received by the HTTP handler 94, possibly through another connection handler which 
communicates with the transcoding system 86, it is forwarded to the dispatcher 22. The 
dispatcher 22 then prepares a response including the WMLC content and sends the 
response to the mobile device 12. The HTTP handler 94 may instead prepare the 

10 response, which would then be translated (if necessary) by the dispatcher 22 to 
conform to a communication protocol or scheme used by the mobile device. 
Illustratively, the WML content returned by the web server 76 may be stored by the 
HTTP handler 94 in case a data transfer or transcoding error occurs. Local storage of 
the WML content allows an IP Proxy system 84 to re-submit the content, to either the 

15 same transcoder system 86 or a different transcoder system, without having to request 
the content from the web server 76. 

If the requested content is returned by the web server 76 as HTML 
content, then the HTTP handler 94, through another handler if required, would submit 
the HTML content to the transcoder system 86 for chained transcoding using both the 

20 HTML->WML transcoder 1 04b and then the WML->WMLC transcoder 1 04a specified in 
the mobile device request. Such chained transcoding operations may also be specified 
by the mobile device 12 in the connection request. Chained transcoders may either be 
part of the same transcoding system 86 as shown in Fig. 1 0, or implemented in different 
transcoder systems. When a chained transcoding operation involves different 
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transcoder systems, content returned by an information source may first be transmitted 
to one transcoder system for transcoding into an intermediate content type which is 
returned to the IP Proxy system 84, and the intermediate content type may then be sent 
to another transcoder system, for transcoding using the specified transcoder or another 
5 intermediate transcoder in a transcoder chain. Content is preferably forwarded between 
different transcoding systems via the IP Proxy system 84 which is processing the 
connection request, but may instead be directly transmitted from one transcoder system 
to another if compatible data transfer mechanisms have been implemented in each 
transcoding system. 

10 Data request errors or failures, such as transcoder errors or other 

situations in which a specified transcoder is unavailable, may be managed according to 
any of the schemes described above, possibly including such further operations as 
using a different transcoder to transcode content, returning an error message to the 
mobile device 12, returning an error message the web server 76, and controlling any 

15 subsequent processing of a request or content from the mobile device 12 and/or the 
web server 76. 

Push operations for systems with one or more external configuration files 
such as 1 02 will be apparent from the foregoing illustrative examples. A data push may 
be accomplished by a push server 42 substantially as described above, except that a 
20 particular transcoder would be specified in a push request instead of a request from the 
mobile device 12 as shown in Fig. 10. In addition, a push server 42 may consult an 
external configuration file to determine which transcoders are available to an IP Proxy 
system 84 before a push request is submitted. If a required type of transcoder is not 
available, then the push server 42 may determine if any other transcoder operation, 
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• including chained transcoder operations, may be suitable for the push request and an 
intended recipient mobile device 12 and format the push request accordingly, thereby 
possibly avoiding.failures or errors at the IP Proxy system 84. As described above, the 
configuration file 1 02 may be a registry including entries for transcoders available from 

5 one or more transcoder systems. When entries in the configuration file 1 02 include an 
address, such as an IP address, or other identifier of a transcoder system from which a 
particular transcoder is available, then the address may be supplied to an IP Proxy 
system 84 by a push server 42 in a push request. At least some transcoder searching 
operations may thereby be off-loaded from IP Proxy systems 84 to push servers 42. 

10 In the system of Fig. 1 0, it is contemplated that the transcoder system 86 . 

and configuration file 102 may communicate with each other to ensure that the 
configuration file 102 accurately indicates which transcoders are available. A 
configuration file may be associated with a particular type of connection such as HTTP 
connections and thus HTTP connection handlers. If a configuration file 102 is 

15 associated with a particular transcoder system 86, then the configuration file may be 
resident within the transcoding system 86. 

If multiple transcoding systems are implemented, a shared configuration 
file storing transcoder entries for the transcoders available in all transcoder systems 84 
may simplify the transcoder lookup performed by a connection handler. An IP Proxy 

20 system 84 or push server 42 need then only consult a single configuration file to 
determine if appropriate transcoders are available from any transcoder systems with 
which it can communicate. This single configuration file/server could also support 
protocols to allow external transcoding servers to register. A registration process could 
add a list of available transcoders to the single configuration file, for example. 
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An external transcoding system 86 preferably supports a query function to 
allow a mobile device 12 or a push server 42 to determine which transcoders are 
available before a connection request is prepared and sent to an IP Proxy system 84. 
Some mechanism whereby transcoders can be added to the transcoder system 86 and 
5 configuration file 1 02 would also preferably be supported. A push server 42 may then 
add a new transcoder to the transcoding system 86 and push content that relies on the 
new transcoder to mobile devices such as mobile "device 12 through an IP Proxy system 
84. 

External transcoder systems 86 include download systems from which 
10 transcoders may be downloaded by an IP Proxy system 84 and executed locally (see 
Fig. 9) and remote transcoding systems to which content is sent for transcoding at the 
transcoding system (see Fig. 10). In another embodiment, a "hybrid" transcoder system 
incorporating aspects of both these types of transcoder systems. When a hybrid 
transcoder system is available to an IP Proxy system 84, the IP Proxy system 84 may 
15 either download a required transcoder from the transcoder system or send content to 
the transcoder system to be transcoded remotely. The selection of transcoder download 
or remote transcoding may be dependent, for example, upon the amount of data to be 
transcoded, the complexity of the transcoding (single or chained operations), or other 
criteria. Similarly, chained transcoding operations may involve download transcoding 
20 systems and local transcoder execution as well as remote transcoding systems. 

Example Implementation 

An example implementation of an IP Proxy system will now be described. 
Fig. 11 is a block diagram showing an IP Proxy system implemented in a secure 
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network. 

The system 120 in Fig. 11 includes a mobile device 12 that operates 
within a wireless network 1 4. Through a gateway 1 5, the mobile device can receive and 
preferably also send data over a WAN 1 6 such as the Internet. These elements of the 

5 system 120 are substantially the same as similarly labelled elements in Fig. 1. In the 
system 120 however, the IP Proxy system 124 is configured within a private network 
such as a corporate network 130, behind a security firewall 127, and communicates 
with the gateway 15 through a network server computer 122. In a particular example 
embodiment, the network server 122 is associated with an email system 128. Two 

1 o information sources, an internal source 1 26 and an external source 1 32, are also shown 
in Fig. 11. 

The network server 122 preferably enables secure communication to the 
mobile device 1 2, as indicated by the encryption and decryption blocks 1 22a and 1 22b. 
The network server 1 22 encrypts any communications directed to a mobile device 1 2. 

1 5 The intended recipient mobile device 1 2, using a secret key stored therein, can decrypt 
encrypted communications from the network server 122. A mobile device 12 similarly 
encrypts any information sent to the network server 1 22, which can be decrypted by the 
decryption module 1 22b. Those skilled in the art of cryptography will appreciate that the 
keys and encryption algorithms used at the network server 122 and mobile device 12 

20 are preferably chosen so that it would be computationally infeasible to decrypt 
encrypted information without the required secret key. One preferred encryption 
scheme is triple-DES (Data Encryption Standard). 

Key distribution between a network server 122 and a mobile device 12 
may be accomplished via a secure connection such as a secure physical connection 
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between the mobile device 12 and the network server 122, or between the mobile 
device 12 and another computer within the corporate network. Known public key 
cryptography techniques may instead be used for key distribution. In a public key 
scheme, a public key is used to encrypt information in such a way that the encrypted 
5 information may be decrypted using a corresponding private key. The public key is 
stored by, and may be retrieved from, a publicly accessible key repository commonly 
referred to as a certificate authority or CA, whereas the private key is stored only at a 
mobile device or system with which the public key is associated. Thus, a network server 
122 or any other sender that wishes to send encrypted information to a mobile device 

10 12 may retrieve the mobile device's public key from a CA and use the public key to 
encrypt information destined for the mobile device 1 2. A mobile device 1 2 may similarly 
obtain a network server's public key from a CA and use the public key to encrypt 
communication signals to be sent to the server. 

Regardless of the particular key distribution scheme and encryption 

15 techniques used, encrypted communications between a mobile device 1 2 and network 
server 122 allows for secure access to corporate or other private information using a 
mobjle device 12. Consider the example of the internal information source 126 within 
the security firewall 127, described below with reference to Fig. 12. Fig. 12 is a signal 
flow diagram illustrating a corporate data access operation. In keeping with the above 

20 illustrative example operations, Fig. 1 2 shows an HTTP-based data access operation. 

In Fig. 12, an HTTP request is encrypted at the mobile device 12, 
preferably using a strong encryption routine such as triple-DES (3DES), before it is sent 
to the network server 1 22 through the wireless network 1 4 (Fig. 1 1 ) and possibly other 
intermediate networks or components like the gateway 15 and WAN 16 shown in Fig. 
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1 1 . The encrypted request is then received by the network server 1 22 and decrypted in 
the decryption module 122b. The decrypted request is forwarded to the IP Proxy 
system 124, which may proceed to process the request substantially as described 
above. The active handler, the HTTP handler 26 in this example, may consult the 
5 configuration file 72 or transcoder lookup table and expand the accepted content types 
to include content types that can be transcoded into the f ormat(s) that can be accepted 
by the mobile device 1 2. A request, possibly including further content types, is then sent 
by the HTTP handler 26 to the information source 126, which then returns requested 
information, in WML format in this example. An appropriate transcoder 74 is loaded and 

1 o invoked by the HTTP handler 26 if necessary and the requested content, preferably in a 
format requested by the mobile device 1 2, is returned to the network server 1 22 through 
the dispatcher 22. The network server 122 then encrypts the content received from the 
IP Proxy system 1 24 in its encryption module 1 22a and sends the encrypted content in 
a response to the mobile device 1 2. In some implementations, the protocol conversion 

15 or translation operations associated with the dispatcher 22 may instead be performed 
by the network server 122. 

The information source 126 may be a computer system or data store 
preferably configured for operation on the private network 130, such as a file server or 
other data store accessible through the network 130. In the example of a corporate 

20 network, the information source 126 may include confidential or otherwise sensitive 
information that an owner of the network 130 strives to keep private. The security 
firewall 1 27 is intended to prevent unauthorized access to private network components 
including the information source 126. In some situations, the very existence of 
information stored at the information source must remain confidential. The encryption 
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of the request from the mobile device as shown in Fig. 12 prevents an unauthorized 
party from determining the contents of the request without breaking the encryption, 
which as described above is not computationally feasible for strong encryption schemes 
such as 3DES. The request remains encrypted until received by the network server 122 
5 and decrypted, behind the security firewall 127, as indicated at 134 in Fig. 12. The 
request is therefore virtually as secure as a request sent from a computer system on the 
network 130. 

Once decrypted, the request is processed by the IP Proxy system 1 24 and 
information source 126 as described above. However, encryption of the requested 

10 content by the encryption module 1 22a in the network server 1 22 before it is sent to the 
mobile device 12 similarly ensures that the content can only be viewed by the mobile 
device 12. Confidential corporate information therefore remains encrypted and thus 
secure until received and decrypted at the mobile device 12, thereby effectively 
extending the security firewall to the mobile device 12. Both the request and the 

15 information returned to the mobile device in response thereto are secure. 

In known remote data access schemes such as WAP, gateway systems 
which provide for data access using mobile devices are normally located outside 
corporate or private premises, at the location of a service provider for example. Any 
confidential or sensitive information encrypted at the private premises is decrypted at 

20 the gateway system, outside the corporate firewall, and then re-encrypted before being 
sent to the destination mobile device or devices. The information is therefore in the 
clear at the gateway system and thus accessible by an owner or operator of the 
gateway system. Furthermore, the owner or operator of a private network from which 
the information was sent typically has no control over security arrangements at the 
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gateway system, such that the information is vulnerable to attacks on the gateway 
system. 

The arrangement shown in Figs. 11 and 12 provides for secure remote 
access to private, confidential or otherwise sensitive information. Information is 

5 encrypted from end-to-end between the network server 1 22 and any mobile device 1 2. 
Any level of security may be implemented at the security firewall 127 to protect 
confidential information stored at an information source such as 126, and when 
encrypted by the network server 122, information is not decrypted at any intermediate 
point before being received at a mobile device 12. The information is in the clear only 

10 "inside" the point 134, behind the security firewall 127, and on the mobile device. 
Security arrangements such as password or passphrase control are also preferably 
implemented at the mobile device 12 to prevent an unauthorized user from using the 
mobile device 12 or decrypting received encrypted information. For example, computer 
workstations may be protected by password-deactivated system locking and access to 

15 a corporate network 130 is normally protected by login passwords. Similarly, a 
password may be required to use a mobile device 1 2, while a different passphrase may 
be necessary to decrypt any encrypted information stored on the mobile device. A 
mobile device 1 2 and information stored thereon is thereby just as secure as a network 
workstation and information stored on a network. Such techniques as limited password 

20 or passphrase entry retries, mobile device 12 or mobile device memory reset after a 
predetermined number of failed password/passphrase entries, dynamic and possibly 
random password/passphrase updates and the like may be used to further improve 
mobile device security. 

For an external information source 1 32 (Fig. 1 1 ), a data access operation 
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is substantially the same as shown in Fig. 12, except that the information source is 
outside the firewall 127. The request and response exchange between the mobile 
device 12 and the network server 122 may be encrypted, but information exchanged 
with the information source 132 may be unsecure. If the information provided by the 
5 information source 1 32 is not private or confidential, then unsecure exchange between 
the IP Proxy system 124 and the source 132 will be sufficient for most purposes. 
However, if the external source 132 provides private information, then alternate 
arrangements are preferably provided. 

One possible measure to improve the security of information being 

10 requested from an external source 1 32 is to secure the communications between the IP 
Proxy system 124 and the source 132. For example, the IP Proxy system 124 may be 
adapted to support Secure HTTP (HTTPS), Secure Sockets Layer (SSL) or other 
secure communication schemes in order to securely access information at the 
information source 132. Information from the source 132 may thereby be securely 

15 transferred to the IP Proxy system 124 and is then protected by the security firewall 
1 27. Encrypted information may be decrypted by the I P Proxy system 1 24, by the active 
connection handler for example, and transferred to the network server 122, which then 
encrypts the information for transmission to the mobile device 1 2. As above, information 
is only in the clear behind the firewall 127. Alternatively, a secure communication 

20 session may be established between the mobile device 1 2 and source 1 32 through the 
IP Proxy system 124. In the system of Fig. 11, communications between the mobile 
device 12 and network server 122 would then be double-encrypted. 

As shown in Fig. 1 1 , the network server 122 is also associated with the 
email system 128. In one embodiment, the network server 122 provides redirection of 
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data items from the email system 128 to mobile device 12. One such system is 
described in detail in United States Patent 6,21 9,694, entitled "System And Method For 
Pushing Information From A Host System To A Mobile Data Communication Device 
Having A Shared Electronic Address", and issued to the assignee of the present 

5 application on April 17, 2001. The complete disclosure of this patent is hereby 
incorporated into this application by reference. 

Since the network server 122 is also associated with the IP Proxy system 
124, integrated functionality between the email system 128 and the IP Proxy system 
124 may be possible. In one embodiment, the IP Proxy system 124 uses encryption 

10 functionality of the network server 122 as well as a transport mechanism via which the 
network server 122 communicates with the mobile device 12. Other functions of the 
network server 1 22, such as data compression for example, may similarly be exploited 
by an IP Proxy system 124 to improve the efficiency of use of wireless communication 
resources. As described briefly above, content destined for a mobile device 1 2 may be 

15 addressed to the mobile device using an email address in the email system 128 
associated with the mobile device user. In this example, content forwarded to the 
mobile device 12 by the IP Proxy system 124 may also be stored in the user's mailbox 
on email system 128 by the network server 122, as indicated in Fig. 11, to thereby 
provide both a record of IP Proxy system operations and a stored copy of any 

20 forwarded content. Other integrated functions may include but are in no way limited to 
email-based content requests from mobile devices and addressing of mobile device- 
destined information by the IP Proxy system 1 24 using an email address on the email 
system 128. Still further integrated functions may be enabled where a network server 
122 or the IP Proxy system 124 is associated with any other services. 
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It will be appreciated that the above description relates to exemplary 
embodiments by way of example only. Many variations on the invention will be 
apparent to those of ordinary skill in the art, and such variations are within the scope of 
the invention as described, whether or not expressly described. 

5 For example, embodiments of the invention have been described primarily 

in the context of an IP-based system. Similar proxy systems for other types of 
communication systems are also contemplated within the scope of the invention. Other 
types of connections, connection handlers and transcoders than those described above 
will also be apparent to those skilled in the art. 

10 Depending upon the particular implementation of a remote data access 

system and the features to be supported, not all of the elements shown in Fig. 2 are 
required. Where push sen/ices are not supported for example, the proxy system will not 
include push services 30. 

The instant invention is also in no way limited to content type indication 

15 using MIME types. MIME types are useful in conjunction with the instant invention, but 
are not required, to practice the invention. Other content type indicators may be 
substituted for MIME type to indicate the type or format of requested or received 
content. 

Although the transcoders described above convert between well-known 
20 information types or formats, custom transcoders pould be developed and implemented 
for virtually any information format, including for example application program file types 
and proprietary formats. As described above, a proxy system in accordance with the 
instant invention is preferably configurable and new content transcoders may be added. 

It is also possible that information content from an information source may 
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include multiple different content types, not just a single content type as described 
above. For such multiple-type content, transcoders may be selected, for example, to 
transcode the content into a single content type, or into multiple content types accepted 
at a mobile device. In the case of transcoder selection by a mobile device or 

5 information source as described above, a list of transcoders for any or each part of 
multiple-type information type content may be specified in a connection request, a 
response to a request, or a push request. A respective transcoder may be specified 
and used for each part of the information content having a particular content type. 
Respective transcoders may be selected for- each of the multiple content types based 

10 on different selection schemes. For example, when the multiple contenttypes include a 
first content type and a second content type, a transcoder may be specified for the first 
content type, whereas a transcoder for the second content type may be selected based 
on a type or identifier of a mobile device or information source. 

When any part of multiple-type information content cannot be transcoded 

1 5 as specified, where a specified transcoder is not available for example, only other parts 
of the information content might be transcoded and sent to a mobile device. 
Alternatively, a default transcoding operation as described above may be used to 
transcode parts of multiple-type content. Non-transcoded parts of multiple-type content, 
or possibly all of the multiple-type content, could instead be replaced with a link or other 

20 information that may be used to subsequently access the information content or parts 
thereof, and sent to a mobile device. Information indicating the multiple content types 
and/or required or recommended transcoders could also be sent to the mobile device. 
The information content or parts thereof may then be retrieved by the mobile device by 
submitting a connection request or possibly further transcoding instructions or an 
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alternate transcoder selection to an IP Proxy system. 

Furthermore, a proxy system may be implemented in any network, not 
only in a corporate network as shown in Fig. 1 1 . Installation of a proxy system in an ISP, 
ASP, or Virtual Network Operator (VNO) system would provide for secure remote 
5 access to network information and secure transfer of information between any network 
users, including transfers between mobile devices of ISP, ASP or VNO users. 

Although the invention has been described in detail with reference to certain 
illustrative embodiments, variations and modifications exist within the scope and spirit of 
the invention as described and defined in the following claims. 
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What is claimed is: 

1 . A system for providing information content over a network to a wireless 
mobile communication device, comprising: 

a transcoding system comprising a plurality of transcoders, each transcoder 
5 operable to transcode the information content from a respective input content type 
into a respective output content type; and 

a first network device in communication with the transcoding system and 
comprising a connection handler system, the first network device operable to receive 
a first connection request comprising transcoder request data and to select a 
10 corresponding connection handler operable to select one or more transcoders from 
the plurality of transcoders based on the transcoder request data. 

2. The system of claim 1 , wherein the first network device is further 
operable to transmit the information content transcoded into an output content type 

15 to the wireless mobile communication device. 



3. The system of claim 1 , wherein the transcoding system is further 
operable to transmit the information content transcoded into an output content type 
to the wireless mobile communication device. 

4. The system of claim 1 , wherein the transcoder request data identifies a 
requested transcoder. 

5. The system of claim 4, wherein the transcoding system comprises a 
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configuration file associated with the plurality of transcoders, and the connection 
handler is operable to search the configuration file to determine whether the 
requested transcoder is one of the plurality of transcoders and to select the 
requested transcoder where the requested transcoder is one of the plurality of 
5 transcoders. 

6. The system of claim 5, wherein the connection handler is further 
operable to transmit an error message to the wireless mobile communication device 
where the requested transcoder is not one of the plurality of transcoders. 

10 

7. The system of claim 6, wherein the connection handler is further 
operable to receive alternate transcoder request data in response to the error 
message, the alternate transcoder request data identifying an alternate transcoder. 

15 8. The system of claim 5, wherein the connection handler is further 

operable to transmit a list of selectable transcoders to the wireless mobile 
communication device where the requested transcoder is not one of the plurality of 
transcoders. 

20 9. The system of claim 8, wherein the connection handler is operable to • 

receive selected transcoder data from the wireless mobile communication device 
and to select one of the selectable transcoders from the list of selectable 
transcoders based on the selected transcoder data. 
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1 0. The system of claim 5, wherein the connection handler is further 
operable to discard the information content where the requested transcoder is not 
one of the plurality of transcoders. 

5 11-. The system of claim 5, wherein the connection handler is further 

operable to pass the information content where the requested transcoder is not one 
of the plurality of transcoders. 

12. The system of claim 5, wherein the transcoding system is further 

10 operable to transcode the information content into a content type forwarded to the 
wireless mobile communication device in response to a previous connection request 
where the requested transcoder is not one of the plurality of transcoders. 

13. The system of claim 4, wherein the connection handler is further 
operable to determine whether the requested transcoder is one of the plurality of 
transcoders, and, where the requested transcoder is not one of the plurality of 
transcoders, to determine a type of the wireless mobile communication device and to 
select one or more transcoders from the plurality of transcoders based on the type of 
the wireless mobile communication device. 

14. The system of claim 4, wherein the connection handler is further 
operable to determine whether the requested transcoder is one of the plurality of 
transcoders, and, where the requested transcoder is not one of the plurality of 
transcoders, to determine an address associated with the wireless mobile 



15 
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communication device and to select one or more transcoders from.the plurality of 
transcoders based on the address of the wireless mobile communication device. 



1 5. The system of claim 4, wherein the information content originates at an 
5 information source, and wherein the connection handler is further operable to 

determine whether the requested transcoder is one of the plurality of transcoders, 
and, where the requested transcoder is not one of the plurality of transcoders, to 
determine an address of the information source and to select one or more 
transcoders from the plurality of transcoders based on the address of the information 
10- source. 

16. The system of claim 1 , wherein the transcoder request data comprises 
a list of one or more accepted content types in order of preference. 

15 17. The system of claim 1 6, wherein the connection handler is operable to 

select from the plurality of transcoders based on the order of preference of the list of 
one or more accepted content types. 

18. The system of claim 1 , wherein the connection handler is further 
20 operable to transmit a list of selectable transcoders to the wireless mobile 
communication device upon receiving the transcoder request data, to receive 
selected transcoder data from the wireless mobile. communication device, and to 
select one or more of the selectable transcoders from the list of selectable 
transcoders based on the selected transcoder data. 
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1 9. The system of claim 1 , wherein the transcoder request data comprises 
a network address specifying the location of a transcoder. 

20. . The system of claim 19, wherein the transcoding system is operable to 
access the location specified by the network address, to retrieve the transcoder, and 
to store transcoder data associated with the transcoder in a configuration file. 

21 . The system of claim 1 , wherein the transcoding system is operable 
generate and store mapping data comprising transcoding chains, each transcoding 
chain selecting one or more of the plurality of transcoders to transcode the 
information content from a respective input content type into a respective output 
content type. 

22. The system of claim 21 , wherein the transcoding system comprises a 
configuration file including transcoder data associated with the plurality of 
transcoders, and wherein the mapping data is updated upon the addition or deletion 
of transcoder data. 

23. . The system of claim 21 , wherein the connection handler is further 
operable to select a transcoding chain to transcode the information content from the 
input content type into the output content type based on user defined criteria. 

24. The system of claim 23, wherein the user defined criteria includes data 
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25. The system of claim 1 , wherein: 

the information content includes multiple content types; and 
the transcoder request data identifies a respective requested 
transcoder for at least one of the multiple content types. 

26. A method for providing information content over a network to a mobile 
communication device, comprising the steps of: 

receiving a connection request including a transcoder request for a requested 
transcoder; 

establishing a connection with an information source responsive to the 
connection request; 

receiving information content from the information source; 

providing a plurality of transcoders, each transcoder configured to transcode 
information content from a respective input content type into a respective output 
content type; 

selecting one or more transcoders from the plurality of transcoders based on 
the transcoder request; 

transcoding the information content using the one or more transcoders 
selected to generate transcoded information; and 

sending the transcoded information content to the mobile communication 
device. 
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27. The method of claim 26, wherein the step of receiving a connection 
request comprises the step of receiving a connection request from the mobile 
communication device. 

5 28. The method of claim 26, wherein the connection request identifies the 

information source. 

29. The method of claim 26, wherein the step of selecting one or more 
transcoders from the plurality of .transcoders based on the transcoder request 

1 o comprises the steps of: 

determining whether the requested transcoder is one of the plurality of 
transcoders; 

selecting the requested transcoder where the requested transcoder is one of 
the plurality of transcoders; and 
15 where the requested transcoder is not one of the plurality of transcoders: 

determining a requested output content type of the requested 

transcoder; 

determining a received content type of the information content; and 
selecting one or more transcoders to transcode the information content 
20 from the received content type to the requested output content type. 

30. The method of claim 26, wherein the step of establishing a connection 
with an information source responsive to the connection request comprises the step 
of sending an information request to the information source. 
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31 . The method of claim 30, wherein the connection request identifies one 
or more accepted content types. 

32. The method of claim 31 , further comprising the steps of: 
determining whether any of the plurality of transcoders are configured to 

transcode any further content types, into any of the one or more accepted content 
types where the requested transcoder is not one of the plurality of transcoders; and 

including the one or more accepted content types and the further content 
types in the information request. 

33. The method of claim 32, wherein the step of determining whether any 
of the plurality of transcoders are configured to transcode any further content types 
into any of the one or more accepted content types where the requested transcoder 
is not one of the plurality of transcoders comprises the steps of: 

determining a requested output content type of the requested transcoder; and 
comparing the requested output content type to the respective output content 
types of each of the plurality of transcoders. 

34. The method of claim 26, further comprising the steps of: 
determining whether the requested transcoder is one of the plurality of 

transcoders; and 

discarding the information content where the requested transcoder is not one 
of the plurality of transcoders. 

-. 
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35.. The method of claim 26, further comprising the steps of: 
determining whether the requested transcoder is one of the plurality of 
transcoders; and 

5 performing a default transcoding operation on the information content where 

the requested transcoder is not one of the plurality of transcoders. 

36. The method of claim 35, wherein the default transcoding operation 
comprises the step of passing the information content. 

10 

37. The method of claim 35, wherein the default transcoding operation 
comprises the step of transcoding the information content into a content type 
forwarded to the mobile communication device in response to a previous connection 
request. 

15 

38. The method of claim 26, further comprising the step of transmitting a 
list of selectable transcoders to the mobile communication device where the 
requested transcoder cannot be selected. 

20 39. The method of claim 35, further comprising the step receiving another 

connection request where the requested transcoder cannot be selected, the other 
connection request comprising an alternate transcoder request. 

40. The method of claim 26, wherein the transcoder request comprises a 
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network address specifying the location of the requested transcoder, and the step of 
selecting one or more transcoders from the plurality of transcoders based on the 
transcoder request comprises the steps of: 

accessing the location specified by the network address; and 

retrieving the requested transcoder. 

41 . The method of claim 26, wherein the step of transcoding the 
information content using the one or more transcoders selected comprises the steps 
of: 

transcoding the information content into an intermediate content type; and 
transcoding the information content from the intermediate format into a final 
content type. 

42. The method of claim 26, wherein the step of transcoding the 
information content using the one or more transcoders selected comprises the steps 
of: 

sending the information content to a transcoding system; and 

receiving the transcoded information content from the transcoding system. 

43. The method of claim 26, wherein the step of sending the transcoded 
information content to the mobile communication device comprises the step of 
encrypting the transcoded information content. 

44. The method of claim 26, wherein the step of sending the transcoded 
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information content to the mobile communication device comprises the step of 
compressing the transcoded content. 

45. The method of claim 26, wherein the information source is a private 

5 information source configured to operate within a private computer network behind a 
security firewall. 

46. The method of claim 26, further comprising of steps of: 
determining whether the requested transcoder is one of the plurality of 

10 transcoders; and 

where the requested transcoder is not one of the plurality of transcoders: 

receiving a list of transcoders according to an order of preference; and 
selecting one or more of the transcoders in the list of transcoders 
based on the order of preference. 

15 

47. The method of claim 26, further comprising of steps of: - 
determining whether the requested transcoder is one of the plurality of 

transcoders; and 

where the requested transcoder is not one of the plurality of transcoders: 
20 determining a type of the mobile communication device; and 

selecting one or more of the plurality of transcoders based on the type 
of the mobile communication device. 

48. The method of claim 26, further comprising of steps of: 
determining whether the requested transcoder is one of the plurality of 
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transcoders; and 

where the requested transcoder is not one of the plurality of transcoders: 
determining an identifier associated with the mobile communication 

device; and 

5 selecting one or more of the plurality of transcoders based on the 

identifier. 

49. The method of claim 26, further comprising the steps of: 
determining whether the requested transcoder is one of the plurality of 

10 transcoders; and 

where the requested transcoder is not one of the plurality of transcoders: 
determining an identifier associated with the information source; and 
selecting one or more of the plurality of transcoders based on the 

identifier. 

15 

50. The method of claim 26, wherein: 

the information content comprises multiple content types; 
the step of selecting one or more transcoders comprises the step of selecting 
a respective transcoder for at least one of the multiple content types. 

20 

51 . The method of claim 50, wherein the multiple content types comprise 
at least a first content type and a second content type, wherein the transcoder 
request identifies a requested transcoder for the first content type, and wherein the 
step of selecting one more transcoders comprises the steps of: 
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selecting the requested transcoder for the first content type; and 
selecting at least one of the plurality of transcoders for the second content 

type. 

5 52. The method of claim 51 , wherein the step of selecting at least one of 

the plurality of transcoders for the second content type comprises the step of 
selecting at least one of the plurality of transcoders for the second content type 
based on the respective input content type of the plurality of transcoders. 

10 53. The method of claim 51 , wherein the step of selecting at least one of 

the plurality of transcoders for the second content type comprises the step of 
selecting at least one of the plurality of transcoders for the second content type 
based on a type of the mobile communication device. 



15 54. The method of claim 51 , wherein the step of selecting at least one of 

the plurality of transcoders for the second content type comprises the step of 
selecting at least one of the plurality of transcoders for the second content type 
based on an address of the information source. 

20 55. The method of claim 26, wherein the respective output content types 

include one or more content types selected from the group consisting of Wireless 
Markup Language (WML), Hypertext Markup Language (HTML), compiled WML 
(WMLC) and Extensible Markup Language (XML). 
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56. A system for providing remote data access to a mobile communication 
device, comprising: 

means for receiving a connection request, the connection request comprising 
a transcoder request for a requested transcoder; 
5 means for establishing a connection with an information source responsive to 

the connection request; 

means for receiving information content from the information source; 
means for providing a plurality of transcoders and for transcoding the 
information content using one or more of the plurality of transcoders, each 
10 transcoder being configured for transcoding information content from a respective 
input content type into a respective output content type; 

means for selecting the requested transcoder from the plurality of transcoders 
based on the transcoder request; and 

means for sending the transcoded information content to the mobile 
15 communication device. 

57. The system of claim 56, wherein the means for receiving a connection 
request comprises means for receiving a connection request from the mobile 
communication device. 

20 

58. The system of claim 57, wherein the connection request identifies the 
information source and the information content. 



59. The system of claim 58, wherein the connection request identifies the 
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60. The system of claim 56, wherein the means for establishing a 
connection with an information source responsive to the connection request 
comprises means for sending an information request to the information source. 

61. The system of claim 60, wherein the connection request identifies one 
or more accepted content types. 

62. The system of claim 61 , wherein: 

the means for selecting the requested transcoder from the plurality of 
transcoders based on the transcoder request comprises means for determining 
whether any of the plurality of transcoders are configured to transcode any further 
content types into any of the one or more accepted content types; and 

the means for establishing a connection with an information source 
responsive to the connection request is further adapted for including the one or more 
accepted content types and the further content types in the information request. 

63. The system of claim 62, wherein the means for determining whether 
any of the plurality of transcoders are configured to transcode any further content 
types into any of the one or more accepted content types comprises means for 
searching the plurality of transcoders for transcoders configured to transcode 
information content into the accepted content types. 
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64. The system of claim 56, wherein the means for selecting the requested 
transcoder from the plurality of transcoders based on the transcoder request 
comprises means for discarding the information content where the requested 
transcoder cannot be selected. 

5 

65. The system of claim 56, wherein the means for providing a plurality of 
transcoders and for transcoding the information content using one or more of the 
plurality of transcoders comprises means for performing a default transcoding 
operation on the information content where the requested transcoder cannot be 

10 selected. 

66. The system of claim 56, wherein: 

the information content comprises multiple parts having respective content 
types; and 

15 the connection request comprises a transcoder request for respective 

requested transcoders for at least one of the respective content types. 

67. The system of claim 66, wherein the means for selecting the requested 
transcoder comprises means for performing a default transcoding operation on any 

20 of the multiple parts of the information content for which the respective requested 
transcoder cannot be selected. 

68. The system of claim 64, wherein the default transcoding operation 
passes the information content. 
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69. The system of claim 64, wherein the default transcoding operation 
transcodes the information content into a content type forwarded to the mobile 
communication device in response to a previous connection request. 

70. The system of claim 56, further comprising means for transmitting a list 
of selectable transcoders to the mobile communication device where the requested 
transcoder cannot be selected. 

71 . The system of claim 56, wherein the transcoder request comprises a 
network address specifying the location of the requested transcoder, and the means 
for selecting the requested transcoder from the plurality of transcoders based on the 
transcoder request comprises means for accessing the location specified by the 
network address and for retrieving the requested transcoder. 

72. The system of claim 56, wherein the means for providing a plurality of 
transcoders and for transcoding the information content using one or more of the 
plurality of transcoders comprises means for transcoding the information content into 
as intermediate format and for transcoding the information content from the 
intermediate format into a final format. 

73. The system of claim 56, wherein the means for providing a plurality of 
transcoders and for transcoding the information content using one or more of the 
plurality of transcoders comprises: 
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means for sending the information content to a transcoding system; and 
means for receiving transcoded information content from the transcoding 
system. 

5 74. The system of claim 56, further comprising means for encrypting the 

transcoded information content. 



75. The system of claim 60, wherein the information request includes the 
respective input content type and the respective output content type of the 
1 o requested transcoder. 



. 76. A system for providing information content over a network, comprising: 
a mobile communication device operable to transmit a first connection 
request over the network, the first connection request comprising transcoder request 
15 data identifying a requested transcoder; 

wherein the requested transcoder is operable to transcode the information 
content into a content type that is accepted by the mobile communication device. 

77. The system of claim 76, wherein the transcoder request data further 
20 comprises a network address specifying the location of the requested transcoder. 

78. The system of claim 76, wherein the transcoder request data further 
comprises a list of alternate transcoders, each alternate transcoder operable to 
transcode the information content into a content type that is accepted by the mobile 
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communication device. 

79. The system of claim 76, wherein the transcoder request data further 
comprises a list of acceptable content types in order of preference, and wherein the 
requested transcoder is operable to transcode the information content into a content 
type corresponding to the acceptable content type first in the order of preference. 

80. The system of claim 76, wherein the transcoder request data further 
comprises user priorities including high data priority and high time priority. 

81 . The system of claim 76, wherein the mobile communication device is 
further operable to encrypt the first connection request prior to transmitting the first 
connection request over the network. 
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